Devices & telemetry — the device bounded context
The device registry from commissioning to decommissioning, the telemetry plane — ingest, time-series store, live stream — alert evaluation and acknowledgement, the product & schema catalogs, and remote device commands for every frigo / koelkast unit in the field. A core subdomain: the monitored converged micro data center is the product.
1Ownership & boundaries
The Devices service owns two stores with one boundary between them: the relational registry (Device, Alert) and the time-series plane outside Postgres. Devices ingest over mTLS directly — never through the BFFs or the user gateway — and only Alert rows cross into the relational model (SVC-9, the ⚠ the ERD records under PTL-1).
Reads from: Structure (SiteId) · Tenancy (CustomerId) · Coverage (the scope resolver for every partner read). Portal is the primary client; commissioning arrives from the won-deal saga.
2Ubiquitous language
The words this context uses — the same in code, conversation and spec.
3Aggregates & invariants
The consistency boundaries — one root each, guarding its invariants in a single transaction; cross-aggregate ties are by identity.
4Context relationships
How this context meets its neighbours, with the integration pattern named on each edge.
5Physical view — the service API
The deployment mapping: this context becomes the Devices service. Paths relative to api.riversync.com/v1, except the ingest plane; access notation per the master.